
2 Chapter 2
Although these are low-impact vulnerabilities, they’re great for learning
how browsers handle redirects in general. In this chapter you’ll learn how
open redirects can be exploited and how to identify key parameters, using
three bug reports as examples.
How Open Redirects Work
Intended redirects often work by accepting a destination URL as a param-
eter in a URL. This parameter tells a browser to send a GET request to the
destination URL. A site is vulnerable to an open redirect when it doesn’t
check that the redirect address is a safe URL, or it redirects the user with-
out notifying them that they’re being redirected. When you’re looking for
these vulnerabilities, keep an eye out for URL parameters that include
certain names, such as url=, redirect=, next=, and so on, which might denote
URLs that users will be redirected to. For example, suppose Google had
functionality to redirect users to Gmail by visiting the following URL:
https://www.google.com/?redirect_to=https://www.gmail.com
In this scenario, when you visit this URL, Google receives a GET HTTP
request and uses the redirect_to parameter’s value to determine where
to redirect your browser. After doing so, Google servers return an HTTP
response with a status code instructing the browser to redirect the user.
Typically, the status code is 302, but in some cases it could be 301, 303,
307, or 308. These HTTP response codes tell your browser that a page has
been found; however, the codes also specify that the browser make a GET
request to the redirect_to parameter’s value, https://www.gmail.com/, which
is denoted in the 30x HTTP responses’ Location header. The Location header
specifies where to redirect GET requests.
Now, suppose we change the original URL to the following:
https://www.google.com/?redirect_to=https://www.<attacker>.com
If Google isn’t validating that the redirect_to parameter is for one of
its own legitimate sites where it intends to send visitors, an attacker could
substitute the parameter with another URL. As a result, an HTTP response
could instruct your browser to make a GET request to https://www.<attacker>
.com/. After the attacker has you on their malicious site, they could carry
out other attacks.
Although the parameter in this example was clearly labeled, keep in
mind that redirect parameters might not always be obviously named: param-
eters will vary from site to site or even within a site. In some cases, parameters
might be labeled with just single characters, such as r= or u=.
In addition to parameter-based attacks, HTML meta refresh tags and
JavaScript can redirect browsers. HTML <meta> tags can tell browsers to
refresh a web page and make a GET request to a URL defined in the tag’s
content attribute. Here is what one might look like:
<meta http-equiv="refresh" content="0; url=https://www.google.com/"